Entwicklung ◦
Datenbanken ◦
Programme ◦
Tabellenblätter ◦
?Viele Probleme lassen sich besser lösen, wenn man sie schrittweise angeht. Dieses Thema beschreibt die wichtigsten Schritte der Anwendungsentwicklung und verweist auf die Phasendokumente, welche die Kommunikation zwischen Entwicklern, Auftraggebern und Anwendern begleiten. Phasendokumente erleichtern nicht zuletzt auch die Wartung und Anpassung des Softwareprodukts.
Phasendokumente
1
Spezifikationsphase
-
Dokument S1: Grobspezifikation
Die Grobspezifikation skizziert die groben Produktanforderungen aus der Sicht des Endbenutzers. Meist wird sie durch den Auftraggeber an das Entwicklungsteam herangetragen. Eine endgültige Entscheidung über den Projektbeginn fällt aber erst nach einer detaillierten Feinspezifikation und Machbarkeitsstudie (engl. feasibility study).
-
Dokument S2: Feinspezifikation
Die Feinspezifikation kann sehr detailliert sein. Oft nimmt sie sogar Teile der Entwurfsdokumentation vorweg. Zum Beispiel kann Sie bereits die Benutzeroberfläche andeuten. Wenn visuelle Werkzeuge wie Access und Excel vorgesehen sind, dann können sie bereits vor der Implementationsphase als Protyping Tools eingesetzt werden. Die entstehenden Prototypen sind zwar noch "Kulissen" ohne Verarbeitungslogik, erleichtern aber die Beurteilung der Spezifikation durch den Anwender.
Je detaillierter die Feinspezifikation, desto grösser die Wahrscheinlichkeit, dass Spezifikationsentscheidungen später revidiert werden müssen. Im Sinne einer explorativen Projektentwicklung wird deshalb oft zuerst eine Minimalspezifikation erstellt ("lieber ein fahrtüchtiger VW als ein Porsche ohne Fahrwerk"). Eine anforderungsreichere Maximalspezifikation folgt erst später.
2 Entwurfsphase
Während die Spezifikation Fragen nach dem Was eines Projekts beantwortet, formuliert der Entwurf, wie die Anforderungen der künftigen Benutzer erfüllt werden können. Die Entwurfsphase beschränkt sich auf die Struktur der Daten und den Ablauf der Prozesse, ohne auf Codierungsdetails einzugehen. Sie führt in der Regel zu einem zyklischen Entwicklungsmuster, weil sie Fragen aufwirft, die sich nur durch eine Revision der Spezifikation und den erneuten Einbezug der Anwender beantworten lassen. Der Entwurf lässt sich in die Teilphasen Dialogentwurf, Datenentwurf und Modulentwurf gliedern:
-
Der Dialogentwurf beschreibt die geplanten Menüs, Formulare und Berichte:
Dokument E1: Menüstrukur
Dokument E2: Formularentwurf und Berichtsentwurf
-
Aufgrund der Feinspezifikation und des Dialogentwurfs beschreibt und strukturiert der Datenentwurf die benötigten Objekte, Attribute und Beziehungen:
Dokument E3: Data Dictionary
Dokument E4: Datenflussdiagramm und DatenbankstrukturdiagrammOft erstellt man nach dem Abschluss des Datenentwurfs eine Testdatenbank, an der sich später der Modulentwurf und die Implementation (insbesonderer die Testphase) orientieren können.
-
Dokument E5: Modulhierarchie
Damit sich die programmiersprachliche Umsetzung auf technische Details beschränken kann, wird die Anwendungslogik hier entworfen. Der Modulentwurf zerlegt das Projekt in möglichst unabhängige Bausteine (Module) mit klarer Zielsetzung. Die Modulhierarchie ist deshalb Grundlage der Arbeitsteilung im Projektteam.
-
Dokument E6: Modulbeschreibung und Entwurfscode
Modulbeschreibungen und der Entwurfscode sind das Bindeglied zwischen den entworfenen Formularen, Berichten und Datenstrukturen. Nach einer Kurzbeschreibung der Eigenschaften eines Moduls sequenziert der Entwurfscode dessen Aktivitäten. Der algorithmische Kern administrativer Programme ist allerdings klein. Der Hauptakzent liegt auf der Entwicklung der algorithmisch anspruchslosen Benutzerschnittstelle und der (anspruchsvolleren) Manipulation der Daten. Der Modulentwurf verfeinert man die Modulhierarchie der vorangehenden Phase in eine Menge entwurfssprachlicher Algorithmen, die miteinander kommunizieren. Meist verwendet man eine grafische Notation oder formuliert die Logik verbal. Damit die Entwurfssprache besser verständlich ist, lehnt man sie an die Umgangssprache an und vermeidet die strenge Syntax des Programmcode. Man spricht deshalb auch von Pseudocode.
Mehrfachverwendung
3 Implementationsphase
Die Implementation besteht aus der Codierung und dem Test. Die Codierung beginnt mit der Erstellung von Quellprogrammen. Nach deren Übersetzung durch den Compiler wird der Code getestet. Die meisten Entwicklungssysteme unterstützen diese Tätigkeiten mit benutzerfreundlichen Editoren, Testhilfen und Debuggern.
-
Dokument I1: Modulcodierung
Ausgangsprodukte sind die Produkte der vorangehenden Phase (Modulbeschreibung und Entwurfscode). Sie werden oft in die Kommentarköpfe der künftigen Programmodule (vor allem Subroutinen und Funktionen) integriert. Weil der Entwurfscode nur eine grobe Abstraktion des späteren Programms ist, kann er nicht routinemässig und eindeutig in ablauffähigen Programmcode übersetzt werden. Die Verfeinerung des Entwurfscode stellt deshalb logische und programmtechnische Probleme.
Die Implementation wird von einem Codierstandard begleitet, der die Leserlichkeit und Sicherheit des Code verbessern soll. Verständlicher Code ist vor allem dort wichtig, wo mehrere Entwickler an einem gemeinsamen Projekt arbeiten und die Wahrscheinlichkeit späterer Wartungs- und Anpassungsarbeiten gross ist.
-
Dokument I2: Modultest
Die systematische Fehlersuche nennt man Test, das systematische Lokalisieren und Beheben der gefundenen Fehler Debugging.
-
Dokument I3: Systemintegration und Systemtest
Nach dem Test jedes einzelnen Moduls werden diese in ein Programmsystem integriert. Im allgemeinen zeigt sich erst nach dem Zusammenschalten der Module und dem Test der Modulschnittstellen, ob die Gesamtheit der Bausteine ein sinnvolles Ganzes ergibt. Modultests, Systemintegration und Systemtest sind deshalb zusammen meist aufwendiger als die eigentliche Codierungsphase.
-
Unterphase I4: Verteilung der Anwendung an die Benutzer und Wartung
Die Wartung umfasst die Installation, die Beseitigung von Fehlern, die nicht bereits in den vorangehenden Phasen entdeckt und behoben wurden, und laufende Verbesserungen.
Die Phasen eines Softwareprojekts nehmen unterschiedlich viel Zeit und Kosten in Anspruch: Die Test- und Wartungsphasen sind so aufwändig, dass sie zusammen oft die Hälfte der Projektkosten ausmachen. Die programmiersprachliche Codierung verursacht hingegen oft nur einen Zehntel der Gesamtkosten.
Rapid Prototyping
Phasenschemata sind nur grobe Anhaltspunkte. Auf keinen Fall dürfen Sie zu einer rigiden "Wasserfall"-Phasen führen: Eine Entwicklungsphase muss nicht unbedingt abgeschlossen sein, bevor die nächste Phase beginnt. Phasen müssen sich also nicht streng sequenziell folgen, und ihre Ergebnisse sind meist nur vorläufig. Zum Beispiel kann die Feinspezifikation in einer späteren Phase revidiert werden, oder ein Prototyp kann bereits in einer frühen Phase über den Fortgang des Projekts entscheiden.
Der blosse Schreibtischentwurf einer Anwendung, insbesondere ihrer Benutzerschnittstelle, riskiert an den Bedürfnissen der Anwender vorbeizugehen. Zum einen ist es schwierig, eine Feinspezifikation und einen Feinentwurf ohne Demonstration der wichtigsten Eigenschaften zu erstellen. Zum anderen endet der Entwicklungsprozess nie, weil stets Verbesserungen möglich sind. Oft setzt man deshalb eine erste Annäherung an die Detailspezifikation schon bald in einen Prototyp um. Dieser erste Prototyp ist Anlass für Diskussionen unter Entwicklern und Anwendern. Nach einer Verfeinerung der Spezifikation entsteht ein zweiter Prototyp, der den Vorstellungen der Auftraggeber und Anwender besser entspricht. Dieses explorative Vorgehen wird solange wiederholt, bis die Anwenderbedürfnisse befriedigt oder die gesetzte Entwicklungsdauer erreicht ist. Man nennt diese Art der Softwareentwicklung explorativ oder zyklisch.
Die explorative Anwendungsentwicklung darf allerdings nicht dazu führen, dass 'Versuch und Irrtum' den überlegten Top Down-Entwurf verdrängt. Sorgfältige Überlegungen zur Spezfikation, zur Modularisierung und zur Algorithmisierung verhindern Fehler in den späteren Phasen. Vorschnelle Implementationsentscheidungen lassen sich meist nur mit grossem Zeitaufwand korrigieren. Fehler in der 'Paper and Pencil'-Phase lassen sich hingegen leichter verbessern.
Oft ist es nicht nötig, einen vollständigen Prototyp zu erstellen. In Access genügt es zum Beispiel, den Dialogentwurf (Formulare und Berichte) anzudeuten, um dem Auftraggeber oder dem künftigen Anwender einen Eindruck von der Benutzeroberfläche zu geben. Investieren Sie aber nicht zu viel Zeit in das Layout von Formularen, Berichten und Steuerelemente, solange die Benutzeroberfläche noch nicht endgültig ist.
Beschreiben Sie Ihr eigenes Projekt nach dem Vorbild von TESTS, dokumentieren Sie aber detaillierter. Die nähere Ausgestaltung der Phasendokumente I2 und I3 überlassen wir Ihnen. Am besten dokumentieren Sie die beiden Phasen mit Blick auf den Wartungs- und Erweiterungsprogrammierer. Legen Sie dabei den Schwerpunkt auf die Dokumentation der Systemintegration.
